Inventory management system protection for network traffic surge resistant platform

ABSTRACT

A network traffic surge resistant platform is described herein. An example system includes a network storage, and one or more servers configured as a commerce platform including an authentication manager. The commerce platform generates a first secret code and sends the first secret code via a first communication medium associated with a first identifier. The commerce platform also generates a second secret code and sends the second secret code via a second communication medium associated with a second identifier. In response to determining the first input code matching the first secret code and the second input code matching the second secret code, the commerce platform authorizes a transaction associated with a particular browser and associates the transaction with a customer record associated with both the first and second identifiers.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/865,989 entitled “INVENTORY MANAGEMENT SYSTEM PROTECTION FOR NETWORKTRAFFIC SURGE RESISTANT PLATFORM” filed on Jul. 15, 2022. Thisapplication is also related to U.S. patent application Ser. No.17/865,893 entitled “NETWORK TRAFFIC SURGE RESISTANT PLATFORM,” filed onthe Jul. 15, 2022, U.S. patent application Ser. No. 17/865,906 entitled“A DYNAMIC USER INTERFACE FOR A NETWORK TRAFFIC SURGE RESISTANTPLATFORM,” filed on Jul. 15, 2022, U.S. patent application Ser. No.17/865,933 entitled “INVENTORY MANAGEMENT FOR A NETWORK TRAFFIC SURGERESISTANT PLATFORM,” filed on Jul. 15, 2022, and U.S. patent applicationSer. No. 17/865,951 entitled “INVENTORY MANAGEMENT SYSTEM PROTECTION FORNETWORK TRAFFIC SURGE RESISTANT PLATFORM,” filed on Jul. 15, 2022, eachof which is herein incorporated by reference in their entirety.

TECHNICAL FIELD

The present invention is generally related to webhosting of electroniccommerce and, more specifically, management of surge network traffic toan electronic commerce platform.

BACKGROUND

Purchasing high demand goods and/or services, such as popular toys orevent tickets, can be frustrating for consumers and potentiallydebilitating for electronic commerce platform providers. Increasingly,merchants use flash sales or other such events where all or part of theavailable inventory is, for a limited amount of time, offered to a groupof people at a special price and/or is offered as an opportunity topurchase before the general public. Merchants may use such events tooffer benefits to a particular group of customers (e.g., premiummembers, students, faculty, etc.), as a form of price differentiation,and/or to capture the attention of highly motivated customers, etc.Sometimes, instead of a preplanned event, consumer interest in a good orservice is so high that a similar surge in traffic is generated upon aninitial offer of the good or service. In such scenarios, instead ofmanaging infrastructure (e.g., servers, databases, network bandwidth,etc.) for mean site traffic, the merchant's site must be configured tohandle relatively infrequent surges of high network traffic volume thatinclude a large number of requests into the merchant's backendinfrastructure. For example, a flash sale can act like a denial ofservice attack, but where the traffic is legitimate. Often, backendsystems, such as inventory management systems, are built with oldertechnology that cannot handle the massive volume of queries into itsdatabases. Such backend systems can be overwhelmed by these high trafficvalue events.

SUMMARY

Systems and methods for providing an electronic commerce platform thatmanages surges of high network traffic volume while protecting backendcomputing resources are described herein. For an offer of goods and/orservices, the platform provider generates a static package that isplaced in networked storage (e.g., networked object storage, etc.) thatis accessible through a web service interface. The package contains theinformation required to instantiate and render the interface of thestore, as well as information that is necessary to complete atransaction. When the offer is electronically communicated via a link,the linked location on the merchant platform's server includes justenough HTML instructions to retrieve the package from the storage andinstantiate the interface. Based on the contents of the package, theinterface of the merchant platform is then rendered in the browser ofthe customer using the processor and resources of the customer'scomputer (e.g., not resources of the servers of the merchant platform).During this process, the graphical elements of the interface may beretrieved from the networked storage. Based on the contents of thepackage, the rendered interface presents available inventory andperforms cart management (e.g., presenting available inventory,selecting/deselecting goods and/or services to be placed in the cart,etc.) using resources of the customer's computer without making anycalls to a server to query an inventory management system. The interfaceonly performs backend calls (e.g., calls to the merchant platformserver, etc.) when necessary to complete the next stage of thetransaction (e.g., after the customer takes an affirmative step in thetransaction). For example, when the customer clicks on an action buttonthat signals that they desire to proceed with checking out, a call to aninventory server to query the relevant inventory management system(s) ismade to place a temporary hold on the desired inventory. The renderedinterface collects information to authenticate the identity of thecustomer and collects payment information. The interface then performsbackend calls to the relevant system (e.g., the payments system, thecustomer management system, etc.) to verify the customer's informationand process the payment. After, the payment is processed and thecustomer is identified, the merchant platform makes a call to theinventory management system to reserve the goods and/or services for thecustomer.

To authorize and identify a user, a user interface requests twoidentifiers from a user. The identifiers do not need to be present inthat combination in a user database. The identifiers are linked to othermethods of communicating with the user, such as a mobile number, anemail address, and/or an instant messenger name, etc. The platformdetermines whether the identifiers are present in that combination inthe user database. The user account is indexed to the combination ofidentifiers such that any account with either one of the two identifiersin combination with any other identifier would be a different account.Simultaneously with the account lookup, (i) the platform presents afirst authorization challenge to the user based on the first identifierand (ii) sends a first one-time password (OTP) to the user via the firstidentifier. When the user correctly enters the first OTP into theauthorization challenge interface, the platform presents a secondauthorization challenge to the user based on the second identifier and(ii) sends a second one-time password (OTP) to the user via the secondidentifier. When the user correctly enters the second OTP into theauthorization challenge interface and when the user account exists thatis associated with both identifiers, the platform authorizes the userand associates activity on the platform with the user. When the usercorrectly enters the second OTP into the authorization challengeinterface and when the user account that is associated with bothidentifiers does not exist, the platform creates the account, authorizesthe user, and associates activity on the platform with the user.

An example network traffic surge resistant system includes networkstorage, and one or more servers configured as a commerce platform thatincludes an authentication manager. The commerce platform generates ascript, an offer package, and an offer instantiator and stores thescript and the offer package onto the network storage. The offerinstantiator provides the location of the script and the offer packagein the network storage. In response to a browser operating on acomputing device accessing the offer instantiator, the offerinstantiator causes the browser to retrieve the script and the offerpackage from the network storage. In response to a signal from thecommerce platform, the script, based on the offer package, causes thebrowser to instantiate an authorization interface to receive entry offirst and second identifiers and first and second input codes. Theauthentication manager generates a first secret code and sends the firstsecret code via a first communication medium associated with a firstidentifier. The authentication manager also generates a second secretcode and sends the second secret code via a second communication mediumassociated with a second identifier. In response to determining thefirst input code matching the first secret code and the second inputcode matching the second secret code, the authentication managerauthorizes a transaction associated with a particular browser andassociates the transaction with a customer record associated with boththe first and second identifiers.

An example method to provide a surge resistant online platform includesgenerating, by the online platform including an authorization manager, ascript, an offer package, and an offer instantiator, and storing thescript and the offer package onto the network storage. The offerinstantiator provides the location of the script and the offer packagein the network storage. The method also includes retrieving, by abrowser operating on a computing device at the direction of the offerinstantiator, the script and the offer package from the network storage.The method includes, in response to a signal from the commerce platform,instantiating, by the script operating in the browser, an authorizationinterface to receive entry of first and second identifiers and first andsecond input codes. The method includes (i) generating, by theauthorization manager or a first authorization service coupled to theauthorization manager, a first secret code and send the first secretcode via a first communication medium associated with the firstidentifier, (ii) generating, by the authorization manager or a secondauthorization service coupled to the authorization manager, a secondsecret code and send the second secret code via a second communicationmedium associated with the second identifier, (iii) and in response todetermining the first input code matching the first secret code and thesecond input code matching the second secret code, authorizing, by theauthorization manager, a transaction associated with the browser andassociating the transaction with a customer record associated with boththe first and second identifiers.

BRIEF DESCRIPTION OF THE DRAWINGS

Operation of the present disclosure may be better understood byreference to the following detailed description taken in connection withthe following illustrations, wherein:

FIG. 1 is a block diagram of an example system to provide an electroniccommerce platform to manage a surge network traffic, according to theteachings of this disclosure.

FIG. 2 is a conceptual diagram of bricks used to construct a packageused to manage the surge network traffic, according to the teachings ofthis disclosure.

FIG. 3 is a conceptual diagram of the packager of FIG. 1 generating anoffer package, according to the teachings of this disclosure.

FIG. 4 is a conceptual diagram of the commerce platform of FIG. 1publishing the offer package, according to the teachings of thisdisclosure.

FIG. 5 illustrates example cart interfaces, according to the teachingsof this disclosure.

FIGS. 6A, 6B, and 6C illustrate an example authorization interface,according to the teachings of this disclosure.

FIGS. 7A and 7B illustrate an example method to provide for a networktraffic surge resistant platform, according to the teachings of thisdisclosure.

FIG. 8 illustrates an example method to perform authorization for anetwork traffic surge resistant platform, according to the teachings ofthis disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to exemplary embodiments of thepresent disclosure, examples of which are illustrated in theaccompanying drawings. It is to be understood that other embodiments maybe utilized, and structural and functional changes may be made withoutdeparting from the respective scope of the present disclosure. Moreover,features of the various embodiments may be combined or altered withoutdeparting from the scope of the present disclosure. As such, thefollowing description is presented by way of illustration only andshould not limit in any way the various alternatives and modificationsthat may be made to the illustrated embodiments and still be within thespirit and scope of the present disclosure.

As used herein, the words “example” and “exemplary” mean an instance, orillustration. The words “example” or “exemplary” do not indicate a keyor preferred aspect or embodiment. The word “or” is intended to beinclusive rather an exclusive, unless context suggests otherwise. As anexample, the phrase “A employs B or C,” includes any inclusivepermutation (e.g., A employs B; A employs C; or A employs both B and C).As another matter, the articles “a” and “an” are generally intended tomean “one or more” unless context suggests otherwise.

Commerce platforms that offer high demand and/or limited time offers forgood and/or services often require backend systems (e.g., physicaland/or virtual servers, databases, network bandwidth, etc.) that aredeployed to meet or scale to surges in network traffic as a large numberof customers simultaneously attempt to procure the goods and/orservices. For example, platforms that handle ticket sales for majorevents (e.g., sports, concerts, etc.) often see such surges in networktraffic as tickets are released. These surges can be orders of magnitudegreater than the mean or ordinary network traffic and can overwhelm thecommerce platform and its surrounding infrastructure with the flood ofInternet traffic. Managing these sources can be costly and error prone,as it depends on recognizing the surge and differentiating the surgefrom illegitimate traffic (e.g., a denial of service attack, etc.).Additionally, in many cases, some backend systems, such as inventorymanagement systems, are deployed using technology that is hard to scale(if even possible) and cannot handle the volume of requests necessary toservice the traffic. For examples, generally scalability must be part ofthe design of a database and many inventory systems were deployed beforescalability was required. This can lead to slowing, instability and/ortermination of the operation of the ecommerce platform because thenetwork and the backend system cannot cope or adapt quickly to thesurge. Attempted techniques, such as queues and timed inventoryreservation systems, etc., are often not effective in mitigating theeffects of surge in the network traffic and can be used by maliciousactors and/or undesirable consumers to deny some or all customers accessto purchasing the good and/or services on the commerce platform.Accordingly, there are technical problems that prevent a commerceplatform from being able to manage surges in network traffic volumewithout negatively affecting the backend systems that comprise thecommerce platform.

Generally, platforms provide services that leverage a relationship withthe user, such as having an account associated with the user that theuser can log into. This allows interactions with the user to be trackedwith a common identifier and track and interact with previous uses ofthe platform. For example, the identifier may be associated withtransaction, biographical information, and/or fulfillment information,etc. Traditionally, an account is protected by a set of credentials(e.g., a username and password). When the account is created, the usersupplies a username and a password, the password is hashed and thehashed password is stored in a database and is associated with theusername. When a user logs into the account, the user supplies theusername and a password attempt. The platform performs a database queryto retrieve the hashed password and hashes the password attempt. If thehashed password and the hashed password attempt match, the platformauthorizes the user and associates subsequent activity on the platformwith the user. When an account does not exist, the platform must createone by guiding the user through an account creation process to generatethe username and the password. These actions are centralized on thedatabase managing the users of the platform. During a surge of networktraffic to the platform, queries to the user database also increase andcannot easily be offloaded or distributed to protect the database.

The term “server” has its ordinary meaning. Generally, a server providescomputational services in a request—response model where in response toa request (sometime referred to as a “call”) over a network, the serverperforms some computational action and sends a response back to therequesting computer. As used herein, a “backend call” refers a requestby an interface operating on the computing device of a customer to anon-static network resource (e.g., a server, a database, etc.). A“backend call” generally requires the server(s) of the commerce platformto process the request and generate information to be sent to therequester that is responsive to the contents of the request. Forexample, the backend call may require a query into an inventory databaseto determine status of inventory associated with the offer. Though theintensity can vary, backend calls are relatively computationallyintensive to network resources. The terms “network storage” and “cloudstorage” have their ordinary meaning. Generally, network storageprovides object storage through a web service interface to facilitateremote storage and retrieval of data objects. As used herein, a “staticcall” refers to a request to a static network resource, such asnetworked storage that stores data objects (e.g., visual elements for aninterface, scripts to be executed by the interface, offer packages,etc.). Static calls are relatively computationally inexpensive. As usedherein, an “offer instantiator” refers to a document designed to beprocessed in a web browser that includes (i) a structure (e.g., writtenin HTML code, etc.) necessary to render a cart interface, (ii) alocation of where to receive a related offer package (e.g., fromnetworked storage), and (iii) a location to receive a instantiatingscript to render the cart interface using the structure and the offerpackage.

A merchant that desires to make an offer via a surge traffic resistantcommerce platform (“commerce platform”) generates an offer packagethrough the commerce platform. The offer package contains informationnecessary to render a cart interface and browse inventory associatedwith the offer without making backend calls to the commerce platform orany inventory management system tracking the inventory associated withthe offer. The package may be, for example, generated in adata-interchange format. The package is then stored on one or morestatic network storage devices. To communicate the offer, the commerceplatform creates a link (e.g., a Uniform Resource Locator (URL), etc.)that points to an address that contains the location of the offerpackage, the location of the instantiating script to render the cartinterface, and a minimum amount of code (e.g., HTML, etc.) necessary touse the instantiating script to render the cart interface.

When a consumer activates the link, the consumer's browser fetches theoffer package and the instantiating script to render the cart interface(e.g., by generating browser readable code, etc.) on the commutingdevice executing the browser. That is, instead of a server (e.g., one ofthe servers of the commerce platform) generating the cart interface andthen sending the browser readable code defining the cart interface tothe browser, the computing device of the customer generates the browserreadable code for the cart interface using the instantiating script andbased on the offer package. In such a manner, when a surge of customersare simultaneously or near simultaneously interacting with the cartinterface, a corresponding surge of traffic is not generated directly atthe servers of the commerce platform and those servers are notoverwhelmed by the resulting processing to generate and update the cartinterface. The cart interface includes an action button. The browsergenerated cart interface performs pre-checkout cart management functionsusing the resources of the browser without making inventory or checkoutrelated backend calls to the servers of the commerce platform until theaction button is activated (e.g., “clicked on”) by the customer. Thesepre-checkout cart management functions include browsing inventory (e.g.,names, descriptions, and/or prices of inventory available through theoffer, etc.), receiving an indication of the type and/or quantity thatthe customer desires to purchase, and/or calculating an estimated totalcost of the indicated type and quantity. Because the package includesall of the inventory information (e.g., offer details, identities anddescriptions of inventory available with the offer, price, etc.), thecart interface performs these pre-checkout functions without making anybackend calls. Thus, a surge of customers browsing inventory, many ofwhom are not likely to complete a purchase, does not create acorresponding surge in network traffic or server load for the commerceplatform. From time-to-time, the marching may asynchronously regeneratethe offer package to change any part of the offer, including availableinventory, the theme or template, etc., to replace the previous packageat the same location in the static network storage. Thus, the merchantmay dynamically update the cart interface without causing a surge ofnetwork traffic or server load.

When the customer activates the action button, the browser renders,based on the offer package, a checkout interface and makes a backendcall that includes the identities and quantities of the inventory in thecurrent cart of the cart interface. This backend call causes one of theservers to calculate the actual (e.g., non-estimated) cost, includingthe unit cost of each item and any associated fees, to the items in thecart and report that total to the checkout interface. The customer maychange quantities (e.g., add quantities, subtract quantities, deleteitems, etc.) in the checkout interface. Each changes results in thebackend call to calculate the total cost of the items. These pricecalculations are performed without querying the inventory managementsystem of the merchant. Thus, a large number of such backend calls doesnot result in an increased load on the merchant's inventory managementsystem. In some examples, these backend calls are configured to becomputationally light to reduce any strain on the servers of thecommerce platform.

When the browser receives the calculation, the checkout interfacedisplays the total. The checkout interface performs a redirect to apayment processor. In some examples, this causes the payment processorto instantiate one or more payment electronic widgets (e.g., a Google®Pay widget, an Apple® Pay widget, etc.) and/or a credit card paymentwidget in the checkout interface. Interacting with one of the electronicpayment widgets or the credit card payment widget (e.g., providingpayment credentials, etc.) causes the payment processor to generate apayment intent that places a hold on funds equal to the calculatedamount. Up to this point, the merchant platform does not make any callto the inventory management system of the merchant. After the paymentprocessor signals that the payment intent was successful, the commerceplatform attempts to place a reserve on the items with the inventorymanagement system of the merchant. When the inventory management systemsignals that the attempt to reserve the inventory was successful, thecommerce platform initiates one or more authenticity/security checkswith the customer via the checkout interface. When all of theauthenticity/security checks are successful, the commerce platformrequests that the inventory management system place the reserved itemsbe in a fulfillment status. The commerce platform then signals thepayment processor to complete the transaction based on the purchaseintent. The commerce platform then performs post-purchase fulfillmentactions via the checkout interface. In such a manner, the commerceplatform minimizes network traffic, server load, and load on theinventory management system by only generating such activity when thecustomer has affirmatively signaled their desire to complete atransaction and only to the extent necessary for their current level ofcommitment.

In many instances, users that interact with a platform will do so in amanner such that their identity or a proxy for their identity needs tobe associated with their interactions. Logging into the platformrequires that the user be authorized and authenticated. However, thedatabase that supports a user being authorized and authenticated to aparticular account on the platform needs to be protected during periodsof surges of network traffic that are the result of legitimate trafficintended for the platform. Additionally, a high user throughput isimportant so that traffic generating users are processed quickly as thesurge of traffic progresses so that, for example, users causing networktraffic early in the surge of network traffic can be processed quicklyto mitigate a buildup of user generated traffic. To authorize andidentify a user, a user interface requests two identifiers from a user.The identifiers do not need to be present in that combination in a userdatabase. The identifiers are linked to other methods of communicatingwith the user, such as a mobile number, an email address, and/or aninstant messenger name, etc. The platform determines whether theidentifiers are present in that combination in the user database. Theuser account is indexed to the combination of identifiers such that anyaccount with either one of the two identifiers in combination with anyother identifier would be a different account. Simultaneously with theaccount lookup, (i) the platform presents a first authorizationchallenge to the user based on the first identifier and (ii) sends afirst one-time password (OTP) to the user via the first identifier. Whenthe user correctly enters the first OTP into the authorization challengeinterface, the platform presents a second authorization challenge to theuser based on the second identifier and (ii) sends a second one-timepassword (OTP) to the user via the second identifier. When the usercorrectly enters the second OTP into the authorization challengeinterface and when the user account exists that is associated with bothidentifiers, the platform authorizes the user and associates activity onthe platform with the user. When the user correctly enters the secondOTP into the authorization challenge interface and when the user accountthat is associated with both identifiers does not exist, the platformcreates the account, authorizes the user, and associates activity on theplatform with the user. In such a manner, the platform does not need tocheck a user generated password already associated with an account, candistribute to other servers the authorization functions, and performauthentication functions in parallel. This reduces the burden on theuser database and increases the throughput of user that generate traffictowards the platform.

FIG. 1 is a block diagram of an example system 100 to provide anelectronic commerce platform 102 to manage a surge network traffic. Inthe illustrated example, the commerce platform 102 is communicativelycoupled to the merchant networks (e.g., merchant network 104) andpayment processors 106. The commerce platform 102 is alsocommunicatively coupled to one or more webservers 108 (e.g., physicalservers, virtual servers, and/or virtualized containers, etc.) and oneor more network storage devices 110 (e.g., Amazon® S3, Google® CloudStorage, Azure® Blob Storage, IBM® Cloud Object Storage, etc.). Dataobjects stored in the network storage devices 110 may be pushed ontonetwork storage devices 112 that is part of a content delivery network(CDN) 114 to be accessed by browsers operating on computing devices 116(e.g., desktop computers, laptop computers, smart phones, tablets, smarttelevisions, etc.). The commerce platform 102 facilitates generation ofoffer instantiators 118 and offer packages 120 by a merchant to offergoods and/or services managed by the merchant network 104 through thecommerce platform 102.

The commerce platform 102 includes a transaction application programminginterface (API) 122, a packager 124, an authentication manager 125, anda customer database 126. While in the illustrated example, thetransaction API 122, the packager 124, the customer database 126, andthe webservers 108 are illustrated as being conceptually grouped in acertain configuration for simplicity, these components may be otherwisesituated in any suitable manner (e.g., on cloud servers, etc.). Thetransaction API 122 facilitates communication between the webservers108, the payment processor 106, the merchant network 104, and thecustomer database 126. The packager 124 receives input from the merchantto generate the offer instantiator 118 and the offer package 120 usingsoftware bricks 128. In some examples, the package 124 generates theoffer package 120 in a data-interchange format (e.g., JavaScript ObjectNotation (JSON), Extensible Markup Language (XML), YAML, etc.). Thesoftware brick 128 are offer package components that define theparameters, metadata, available inventory and/or audiovisual assets ofthe offer and the interrelationship between these parameters, metadata,available inventory and/or audiovisual assets. The Customer database 126stores customer information to facilitate assigning an order from acheckout interface in a browser to a particular account or accounts forsecurity and fulfillment purposes. The structure and organization of theoffer package 120 are dictated by which bricks are used to generate theoffer package 120.

Using the packager 124, the merchant defines the offer and provides aninventory data object (e.g., a two dimensional array, etc.) thatspecifies the available inventory for the offer and attributes of theinventory the merchant uses to distinguish the inventory. For example,the data object may include a row for each seat in a venue that is to bepart of the offer and a column for the section, a column for the row,and a column for the seat. The packager 124 generates a unique link(e.g., a URL link, etc.) that instructs a browser where to locate theoffer instantiator 118. The offer package 120 contains the informationnecessary for the offer instantiator 118, when accessed by a browser, torender the cart interface and the checkout interface, including adescription of the available inventory to facilitate a customer browsingthe inventory through the cart interface, without making any backendcalls to the webservers 108 and/or the transaction API 122. After theoffer instantiator 118 and offer package 120 are created, the packager124 publishes the instantiator 118 onto the webservers 108 and pushesthe offer package 120 onto the networked storage 110 and 112. The linkto the instantiator 118 may then be provided to customers. In theillustrated example, the instantiator 118 is located on a server and isaccessible via a domain that is controlled/operated by the commerceplatform 102. Alternatively, in some examples, the instantiator 118 maybe located on a server and accessible via a domain that iscontrolled/operated by another party (e.g., the merchant network 104, athird party, etc.).

The merchant may, from time-to-time, rebuild the offer package 120 withnew and/or updated parameters, metadata, available inventory and/oraudiovisual assets of the offer. When the offer package 120 is rebuilt,the packager 124 pushes the updated offer package to replace the oldoffer package in the networked storage 110 and 112. In such a manner,the merchant can dynamically and asynchronously update the offer package120 while customers access the offer instantiator 118 withoutinterruption.

The example merchant network 104 includes an inventory interface 130 andan inventory database 132 (collectively may be referred to as an“inventory management system” or “IMS”). The inventory interface 130,using the inventory database 132, provides the inventory data object.The inventory interface 130 may also manipulate the inventory in theinventory database 132 by, for example, changing the status of theinventory (e.g., reserving the inventory, marking the inventory forfulfillment, etc.). In some examples, the inventory interface 130 maylimit the frequency at which the packager can request a refresh of theinventory data object.

When a consumer activates the link to the offer instantiator 118, theconsumer's browser performs a static call to retrieve the offer package120 and the instantiating script to render the cart interface (e.g., bygenerating browser readable code, etc.) from the network storage 110 and112. The browser then renders the cart interface by executing theinstantiating script using the offer package 120. The browser generatedcart interface performs pre-checkout cart management functions using theresources of the browser. These pre-checkout cart management functionsinclude browsing inventory (e.g., names, descriptions, and/or prices ofinventory available through the offer, etc.) as defined by the inventorydata object (e.g., as processed by the bricks 128).

When the customer activates the action button, the browser renders,based on the offer package 120, a checkout interface and makes a backendcall that includes the identifiers (sometimes referred to as “inventoryunit identifiers”) that identify inventory in the current cart of thecart interface and quantities of the inventory in the current cart ofthe cart interface. This backend call causes one of the servers 108 tocalculate the actual (e.g., non-estimated) cost, including the unit costof each item and any associated fees, to the items in the cart andreport that total to the checkout interface. The customer may changequantities (e.g., add quantities, subtract quantities, delete items,etc.) in the checkout interface. Each change results in the backend callto the servers 108 to calculate the total cost of the items.

When the browser receives the calculation, the checkout interfacedisplays the total. The checkout interface performs a redirect to thepayment processor 106. In some examples, this causes the paymentprocessor 106 to instantiate one or more payment electronic widgets(e.g., a Google® Pay widget, an Apple® Pay widget, etc.) and/or a creditcard payment widget in the checkout interface. Successfullycredentialing through one of the electronic payment widgets or thecredit card payment widget causes the payment processor 106 to generatea payment intent that places a hold on funds equal to the calculatedamount. After the payment processor 106 signals that the payment intentwas successful, the transaction API 122 attempts to place a reserve onthe items with the inventory management system. When the inventorymanagement system signals that the attempt to reserve the inventory wassuccessful, the transaction API 122 initiates one or moreauthenticity/security checks with the customer via the checkoutinterface. When all of the authenticity/security checks are successful,the transaction API 122 requests that the inventory management systemplace the reserved items in a fulfillment status. The transaction API122 then signals the payment processor 106 to complete the transactionbased on the purchase intent. The transaction API 122 then performspost-purchase fulfillment actions via the checkout interface.

The authentication manager 125 manages authentication of users andprotects the customer database 126 from negative effects of surges innetwork traffic that result in frequent queries into the customerdatabase 126. For example, the authentication manager 125 may limitqueries into customer database 126 (e.g., by only making queries intothe data base after the user has been authenticated) and/or may offloadauthentication actions to other services. The customer database 126includes a customer index and various other pieces of information usedto track the actions of the user (e.g., a transaction history, etc.)and/or fulfill goods and/or services ordered through the platform (e.g.,a mailing address, a billing address, an email address, etc.). Thecustomer index consists at least two identifiers. The identifiers areassociated with methods of independently communicating with the userthrough communication media other than the commerce platform 102 thatthe user has control over and access to. For example, the identifiersmay be an email address, a mobile phone number, and/or an instantmessenger handle, etc. The customer index that points to a particularcustomer record is a unique combination of the at least two identifiers.A customer index with less than all of the identifiers is a differentcustomer index. For example, a customer index of [email:ehendrickson@gmail.com; mobile: 2025550106] is different than thecustomer index of [email: ehendrickson@gmail.com; Telegram:@e*hendrickson].

To complete a transaction as described herein, the authenticationmanager 125 must authenticate the user. This authentication processverifies that the user is a person (i.e., not a computer program), thatthe person is identifiable to the commerce platform 102, and the userhas access to communication means associated with the providedidentifiers. The browser, using the instantiating script used toinstantiate the cart interface, presents one or more interfaces thatinclude authorization challenges to the user. In some examples, theauthorization challenge interfaces request the at least two identifiersand then request the user enter a secret for each identifier. The secretmay be a one-time passcode (e.g., a HMAC-based One-time Passwordalgorithm (HOTP) code, a Time-based One-time Password Algorithm (TOTP)code, a SMS or email-based one-time password (OTP) code, etc.) and/or acode provided by a USB or embedded chip based key (sometimes referred toas a “smartcard” or a “security token”), etc. The request for the userto enter the secret for each identifier may be presented serially or atthe same time (e.g., on the same interface). The authorization manager125 authorizes the user when the secret matches the expected input foreach identifier.

The authorization manager 125 may direct and delegate functionsdescribed herein to authorization services 134 operating on the servers108. The authorization services 134 may be deployable over a group ofthe servers 108 to distribute the computational load caused by the surgeof network traffic. When the user provides the identifiers, theauthorization manager 125 (or one of the authorization services 134)generates the secret (e.g., the OTP) and sends the secret to the userusing the identifier. For example, the authorization manager 125 maysend an email, an SMS text message, an instant messenger message, etc.that contains the OTP. After the user inputs the secret into theauthorization challenge interface, the authorization manager 125determines whether the user has passed or failed the authorizationchallenge by comparing the entered secret to the expected secret.

The authorization manager 125 queries the customer database 126 with theidentifiers to determine whether a customer index exists for the userwithin the customer database 126. In some examples, the authorizationmanager 125 performs this query in parallel with generating and sendingthe secrets for the identifiers so that when the user is authorized, theauthorization manager 125 is ready to associate the current transactionwith the customer index if it exists and create a new customer index toassociate the current transaction if it does not exist. Alternatively,in some examples, the authorization manager 125 performs this queryafter the user has been authorized so that the authorization manager 125does not query the customer database 126 until the user is authorized(e.g., users that eventually never get authorized do not cause queriesinto the customer database 126). In such examples, the authorizationmanager 125 only performs a query into the customer database 126 afterthe user has been authorized, not as part of the authorization process.Additionally, in such examples, the authorization process is performedindependently of the contents of the customer database 126. That is, insuch examples, the contents of the customer database 126 may be accessedto determine what to do once the user is authorized (e.g., associate atransaction with a customer index, etc.), but are not directly used toperform the task of authorization.

FIG. 2 illustrates examples of the bricks 128 used to define andconstruct the offer package 120. The bricks 128 are software structuresthat define the parameters, metadata, available inventory and/oraudiovisual assets of the offer, the interrelationship between theseparameters, metadata, available inventory and/or audiovisual assets, andthe syntax of the data interchange format in which the package 120 isbeing created. When creating the offer package, the merchant may selectthe relevant bricks 128 to define the look and feel, the functionality,inventory management and grouping, and the order flow associated withthe cart interface that is rendered using the offer package 120constructed using the bricks 128 selected and populated by the merchant.The bricks 128 facilitate building the offer package 120 so to includethe necessary parameters, metadata, available inventory and/oraudiovisual assets of the offer and/or tokens point to the parametersand/or metadata to perform front end actions (e.g., the computing device116 rendering the cart interface for the offer) and to perform backendactions (e.g., handle payment, refunds, fund allocation, customerservice, etc.). In the illustrated example, the bricks 128 are arrangedin thematic groups. However, the bricks 128 may be arranged in anymanner. For example, when the packager 124 packages the selected bricks128, into the offer package 120, the resulting structure of the offerpackage 120 mirrors the bricks 128. In some examples, the bricks 128define interface elements that translate the structure of the bricksinto interactable objects within a interface to design an offer. Theinteractable objects have inputs that facilitate receiving theinformation necessary to render the components of, for example, the cartinterface and define relationships between the bricks 128. As such, asbricks 128 are added to an offer, a corresponding interface in an offereditor is generated.

In the illustrated example of FIG. 2 , a group of bricks 128 isclassified in an offer setup group 202. The bricks 128 in the offersetup group 202 are used to build the look and feel of the cartinterface as well as the operation of the cart interface related to thespecific offer. A group of bricks 128 is classified in a payment setupgroup 204. The bricks 128 in the payment setup group 204 are used todefine rules for a transaction made of the specific offer and establisha transactional route and history for every good and/or servicepurchased through the offer. A group of bricks 128 is classified in asale group 206. The bricks 128 in the sales group 206 interface withexternal customer, lead generation, and account databases to connectoffers to the merchant and facilitate merchant account management. Theoffer setup group 202, the payment setup group 204, and the sales group206 contribute structure and metadata to the offer package 120 tofacilitate forensically tracing and justifying any transaction that ismade according to the offer package 120 and to supply a system withinformation to complete a transaction while minimizing the transaction'suse of backend calls.

In the illustrated example, a group of bricks 128 is classified in asecurity group 208. Bricks 128 in the security group 208 provideparameters and metadata used by the authentication manager 125 toperform the authorization challenges to authenticate a customer. Theauthentication/authorization brick 208, for example, may store theparameters and metadata that determine the type and/or form of theidentifiers to be input by the customer (e.g., email address, mobilenumber, instant messenger handle, social media handle, etc.), the userinterface(s) used to enter the identifiers and the associated secrets,the type and/or form of the secrets (e.g., whether numeric oralphanumeric, length, etc.), and/or timing that dictates how long thesecrets are valid, etc. In some examples, there may be multiple versionsof the authentication/authorization brick 208 that may be selected bythe merchant 104, where parameters are predefined.

A group of bricks 128 is classified in an inventory management group210. Bricks 128 in the inventory management group 210 provide parametersand metadata for slicing and presenting inventory in the cart interfaceand interfacing with the inventory management system of the merchant. Agroup of bricks 128 is classified in a fulfillment group 212. Bricks 128in the fulfillment group 128 provide parameters and metadata forfulfilling and delivering inventory after a successful transaction. Agroup of bricks 128 is classified in a marketing group 214 to providesupport to attributing sales of goods and/services to parties involvedin completing the transaction (e.g., first party or third party salesagents, etc.). A group of bricks 128 is classified in a portals group216. Bricks 128 in the portals group 216 provide top level structure topackages, including the offer package 120. A group of bricks 128 isclassified in a customer support group 218 that includes structure,parameters, and metadata to render a customer support interface and toprocess customer support requests while minimizing the number of backendcalls the customer's browser performs.

FIG. 3 is a conceptual diagram of the packager 124 of FIG. 1 generatingan offer package 120. In the illustrated example, a packager interface302 facilitates editing of the contents of the offer package 120. Thepackager interface 302 includes selectors to facilitate selection ofwhich bricks 128 (e.g., and which subbricks, etc.) to use to generatethe offer package 120 and edit the parameters and metadata associatedwith each of the selected bricks 128. These selectors may be graphicalelements that are dragged and moved in the packager interface 302 toselect the bricks 128 and to define relationships between the bricks128. For example, the bricks 128 may specify different widgets 304,different quantity pickers, different themes, different templates,define audio and/or visual assets to be used, different ways to sliceinventory, and/or settings for the authentication manager 125, etc.(collectively referred to as “elements 306”). The merchant 104 may usethe packager interface 302 to specify the parameters of theauthentication/authorization brick 208. The widgets 304 defineinteractive interface elements in the cart interface that causes thehosting browser to perform an action that reaches externally from thebrowser. For example, one widget 304 may define the parameters (e.g.,size, shape, position, label, etc.) of the action button. As anotherexample, one widget 304 may define which third party payment processorto send information to facilitate instantiation of the paymentprocessor's payment interface in the checkout interface.

In the illustrated example of FIG. 3 , the packager 124 includesinput-to-package mapping rules 308 that transform the widgets 304, theelements 306, and, in the illustrated example, the inventory 302expressed in a two-dimensional table into the data interchange formattedfile 312 for the offer package 120. The mapping rules 308 map theinventory 302 and information defined by and through the bricks 128(e.g., the widgets 304 and the elements 306, etc.) into the syntax ofthe data interchange format such that all of the data required to buildthe cart interface and the checkout interface, all of the data toperform cart management functions (e.g., displaying inventory beingoffered, prices, and descriptions; manipulating quantities in the cart;estimating total price, etc.) are included in the offer package 120. Forexample, the mapping rules 308 map the parameters and metadata of theauthentication/authorization brick 208 into the syntax of the datainterchange formatted file 312. When the authentication manager 125handles authentication for a transaction that is based on a particularoffer package 120, the authentication manager 125 by, for example,looking up the particular offer package 120, will know how to authorizethe user that initiated that transaction.

In the illustrated example, the data interchange formatted file 312 is aprocess with package-to-interface rules 314 that specify how theelements will be graphically laid out by the cart interface and/orcheckout interface based on, for example, the selected theme andtemplate bricks and the target browser in which the interfaces will becreated. For example, the data interchange formatted file 312 may beprocessed by different sets for package-to-interface rules 314 togenerate different versions of the offer package 120, where the offerinitiator 120 causes the browser to download one of the versions of theoffer package 120 based on the qualities of the browser. For example, aset of package-to-interface rules 314 may generate one offer package 120for browsers operating on mobile devices (e.g., smart phones, smartwatches, etc.), one offer package 120 for browsers operating oncomputing devices (e.g., desktop computers, tablets, laptop computers,etc.), and one offer package for browsers operating on mixed realitydevices (e.g., virtual reality headsets, augmented reality headsets,etc.). Because the input-to-package rules 308 are processed separatelyfrom the package-to-interface mapping rules 314, the rules sets 308 and314 can be updated asynchronously. That is, the template bricks may beupdated and the update will be implemented the next time the offerpackage 120 is republished.

FIG. 4 is a conceptual diagram of the commerce platform 102 of FIG. 1publishing the offer package 120 and the offer instantiator 118. Atblock 402, the entity using the commerce platform 102 (e.g., themerchant 104, etc.) indicates that the offer instantiator 118 and/or theoffer package 120 should be published. For example, a “publish” buttonmay be provided in the packager interface 302. At block 404, thepackager 124 renders the offer package 120. In some examples, thepackager 124 renders the offer package 120 in accordance to the processdescribed in connection with FIG. 3 above. The packager 124 may performthis rendering multiple times to generate offer packages 120 to be usedby different browsers. At block 406, the packager 124 retrievesdependencies that are specified by the bricks 128 used to create theoffer package 120. The dependencies may be, for example, libraries,audio and/or visual files (e.g., as designated by the selected templatebrick, the selected theme brick, and/or the selected quantity pickerbrick, etc.), and/or link paths (e.g., URLs, etc.), etc. Because bricks128 can be updated asynchronously, dependencies that may have changedsince the last time the offer package 120 was published automaticallyhave those dependencies updated in an offer package when it isrepublished. At block 408, the packager 124 generates the offerpackage(s) 120, the instantiating script used by the browser to generatethe cart and checkout interfaces, and the offer instantiator 118 to bedistributed. In some examples, the packager 124 may perform versioningof the offer package(s) 120 and the instantiating script each time theoffer package(s) is/are republished. The offer instantiator 118 may bechanged to point the browser to the updated instantiating script and/orupdated offer package(s) 120 when the browser refreshes. At block 410,the packager 124 stores the instantiating script, the offer package(s)120, and/or any assets necessary to render the cart interfaces to thenetwork storage 110. At block 412, the packager 124 causes theinstantiating script, the offer package(s) 120, and/or the assets to bedistributed to the networked storage 112 in the CDN 114. In someexamples, the packager 124 sends a signal to the CDN 114 invalidatingthe current cache, which causes the network storage 112 in the CDN 114to update to the latest files. At block 414, the offer instantiator 118is moved to the server(s) 108 to be accessed by the computing devices116.

FIG. 5 illustrates an example cart interface 500, generated by a browserin response to being directed to the offer instantiator 118 based on theinstantiating script and the offer package 120. Once the instantiatingscript and offer package 120 are loaded in the browser, theinstantiating script generates the code and makes the necessary calls toinstantiate the cart interface 500 and perform cart management functionswithout making a backend call. In the illustrated example, the cartinterface 500 includes high level description 502 of the inventory andan inventory item 504 for each piece of inventory being offered. Whilefor illustrative purposes, when only one inventory item 504 is shown,cart interface 500 may include as many inventory items 504 as aredefined in the offer package 120. In some examples, the offer package120 may define inventory items 504 in a nested or hierarchical manner.For example, inventory items 504 for goods may be initially displayed asa list of types of goods that, when clicked, reveal the inventory items504 that fit within that type of good. As another example, for eventtickets, the cart interface 500 may initially display sections, whereeach row within a section is an inventory item 504. The inventory item504 includes a description 506 of the inventory being offered as aquantity picker 508. The quantity picker 508 is a graphical interfacethat facilitates selecting a quantity of the inventory item 504. Thequantity picker 508 may take different form depending on which of thequantity picker bricks was chosen while the offer package 120 wascreated. When the quantity of items in the quantity picker 508 ischanged, the browser, without making a backend call, estimates the totalamount based on the information in the offer package 120 and displaysthe estimated total in the total field 510. Because this calculation isdone entirely within the browser: (a) the calculation is quick, and (b)the manipulation of the inventory in the cart interface 500 does notresult in traffic being directed to the commerce platform 102 and doesnot result in any queries into the IMS of the merchant 104. Using theinstantiating script, based on the offer package 120, this cartmanagement is repeated until the customer interacts with the actionbutton 512. In this manner, the customer may browse the inventory items504 and add items to the cart without any traffic being directed at thecommerce platform 102.

The look and feel of the cart interface 500 is dictated by the selectedtemplate brick and the selected theme brick. The template brick dictateshow the instantiating script, in conjunction with the offer package 120,generates code to define the layout of elements 502, 504, 506, 508 510,512, and 514 within the cart interface 500. If, during block 402 of FIG.4 , the merchant were to select a different template brick or if thetemplate brick definition changed (e.g., changes that would take effectin block 406 of FIG. 4 ), when the customer refreshes the browser, theinstantiating script, in conjunction with the offer package 120, wouldgenerate a changed layout. The selected theme brick dictates theaesthetic look and feel (e.g., color, audio visual assets 512, etc.).If, during block 402 of FIG. 4 , the merchant were to select a differenttheme brick or the theme brick definition changed (e.g., changes thatwould take effect in block 406 of FIG. 4 ), when the customer refreshesthe browser, the instantiating script, in conjunction with the offerpackage 120, would generate a different look and feel of the cartinterface 500.

The cart interface 500 is different from the checkout interface. Thecart interface 500 does not, until the action button 512 is interactedwith, provide a method for the browser, during the course of the userbrowsing the inventory, to perform backend calls. Thus, in the cartinterface 500, selecting and deselecting inventory (e.g., via thequantity picker 508) does not result in network traffic directed towardsthe commerce platform 102. Additionally, in some examples, actuallypurchasing the selected inventory cannot be accomplished through thecart interface 500 (e.g., purchasing is gated by proceeding to thecheckout interface, etc.) As a result, a large number of users cansimultaneously interact with a cart interface 500 instantiated entirelyin their own browser without causing any network traffic to be directedtowards the commerce platform 102. The checkout interface facilitatesthe browser receiving a calculation of actual cost of the selectedinventory (via low processing-load backend calls to the commerceplatform 102) and initiating a purchase of the inventory (viainteraction with a checkout button). Until an actual purchase ofinventory is initiated (e.g., the user interacting with the checkoutbutton), the checkout interface does not cause any queries into the IMSdatabase 132.

FIGS. 6A, 6B, and 6C illustrate an example authorization interfaces600A, 600B and 600C. In the illustrated examples, the authenticationmanager 125 receives identifiers and the secrets (e.g., one-timepasscode, etc.) associated with the identifiers via the authorizationinterfaces 600A, 600B and 600C. FIG. 6A illustrates the entryauthorization interfaces 600A that provides identifier fields 602A and602B for the user to enter identifiers of the specified type. Theauthentication manager 125 does not determine whether or not theidentifier previously exist in the combination entered in the identifierfields 602A and 602B in the customer database 126 before proceeding. Thecombination of identifiers is not checked against the records in thecustomer database 126. From the user's perspective, the progressionthrough the authorization interfaces 600A, 600B and 600C is the samewhether such a record exists or not. In the illustrated example, theentry authorization interfaces 600A also provides name fields 604A and604B for the user to provide one or more of a given name, a surname,and/or a middle name.

FIG. 6B illustrates a first challenge authorization interface 600B thatcorresponds with the identifier entered in one of the identifier fields602A and 602B (e.g., the first identifier field 602A). In theillustrated example, the first identifier field 602A is a mobile number.The first challenge authorization interface 600B provides secret entryfield(s) 606A to facilitate the user entering the secret (e.g., one-timepassword, etc.) received via the means connected to the identifierentered into the first identifier field 602A. For example, when thefirst identifier is a mobile number, the user may receive an SMS messagethat contains a limited duration one-time password to be entered intosecret entry field(s) 606A. As another example, when the firstidentifier is a mobile number, the user may receive a seed value to beentered into an authentication program to generate a one-time user code.FIG. 6C illustrates a second challenge authorization interface 600C thatcorresponds with the identifier entered in one of the identifier fields602A and 602B (e.g., the second identifier field 602B). The secondchallenge authorization interface 600C provides secret entry field(s)606B to facilitate the user entering the secret (e.g., one-timepassword, etc.) received via the means connected to the identifierentered into the second identifier field 602B. For example, when thesecond identifier is an email address, the user may receive an emailthat contains a limited duration one-time password to be entered intosecret entry field(s) 606B.

FIGS. 7A and 7B illustrate an example method to provide for a networktraffic surge resistant platform. The method begins when a user loadsthe offer instantiator 118 into a browser. For example, the user mayclick on a URL that directs the browser to the offer instantiator 118.Generally, the method minimizes traffic generated towards the commerceplatform 102 and queries to the IMS database 132 until the user hasdemonstrated that greater network traffic and database resourceallocation is appropriate. Interface generation (e.g., cart interface500 of FIG. 5 , etc.) and initial cart management are performed by thebrowser using the processing and memory power of the computing device116.

Initially, the browser, based on the instructions provided by the offerinstantiator 118, retrieves the instantiating script and offer package120 from the network storage 112 in the CDN 114 (block 702). Thedistributive nature of the network storage 112 in the CDN 114, coupledto the relatively low processing and network intense activity ofretrieving the instantiating script and offer package 120, means that anetwork traffic surge is not directed at the commerce platform 102, evenwhen a large number of users load the offer instantiator 118 into theirbrowser. The browser, executing the instantiating script, instantiatesthe cart interface in the browser based on the offer package 120 withoutmaking any backend calls to the commerce platform 102 (block 704). Thebrowser receives inventory input (e.g., by manipulation of the quantitypicker 508, etc.) and estimates the price of the selected inventorybased on the offer package 120 without making any backend calls thatresult in queries to the IMS (block 706). The estimated price may bedisplayed in the total field 510 of the cart interface 500. The browserwaits until it receives an inventory input or the user interacts withthe action button 512 (block 708). When the browser receives aninventory input (“NO” at block 708), the browser estimates the price ofthe selected inventory based on the offer package 120 without making anybackend calls that result in queries to the IMS (block 706).

When the browser detects that the user interacts with the action button512 (“YES” at block 708), the browser, using the instantiating script,instantiates the checkout interface based on the offer package 120(block 710). The user may return to the cart interface (e.g., return toblock 704) at any point. The browser, based on the instantiating script,performs a backend call to the commerce platform 102 that includes thecurrently selected inventory of the cart interface (block 712).

The commerce platform 102, in response to receiving the backend call,calculates a price for the currently selected inventory based on theoffer package 120 without generating a query to the IMS of the merchant104 (block 714). The offer package 120 may include obscured and/orencrypted data that commerce platform 102 is able to unobscure and/ordecrypt related to costs beyond the price of the inventory. For example,the commerce platform 102 may calculate the price of the inventory, anyfees specified/allowed by the contract with the merchant 104, and/ortaxes to be levied on the purchase. This is a relatively low processingcost calculation. The commerce platform 102 returns the calculated priceto the browser that issued the backend call (block 716).

The browser, using the instantiating script, displays the calculatedprice in the checkout interface and performs a browser-side redirect(sometimes referred to as a “client-side redirect”) to the third partypayment processor(s) 106 to provide the calculated price (block 718).This allows one or more payment interfaces of the third party paymentprocessor(s) 106 to instantiate within the checkout interface andfacilitate payment for the selected inventory. This browser-sideredirect means that the resources of the browser, not the commerceplatform 102, are used to provide the information necessary for thepayment interface(s) to instantiate. Thus, if the user does not proceedwith checking out, the network resources used by the user towards thecommerce platform 102 have been minimal and no IMS database 132resources have been expended because of the user.

The browser, using the instantiating script, determines whether the userinteracts with the checkout button (block 720). When the user does notinteract with the checkout button (“NO” at block 720), the browser,using the instantiating script, determines whether the user manipulatedthe selected inventory in the checkout interface (block 722). When theuser manipulates the selected inventory (“YES” at block 722), thebrowser, based on the instantiating script, performs a backend call tothe commerce platform 102 that includes the currently selected inventoryof the cart interface (block 712). When the user does not manipulate theselected inventory (“NO” at block 722), the browser determines whetherthe user interacts with the checkout button (block 720). When the userinteracts with the checkout button (“YES” at block 720), the browser,using the instantiating script, performs a backend call that includesthe selected inventory (block 724 of FIG. 7B).

The commerce platform 102 generates a purchase intent to define thetransactions (block 726). The purchase intent is a record of an offeridentifier, a browser identifier, an order identifier, a price, andinventory to be purchased, etc. that facilitates tracking an orderbeginning from the offer instantiator 118 and the offer package 120 tothe checkout process such that any transaction can be audited. Thepurchase intent is linked to the information necessary to verify thecontent of the transaction. The commerce platform 102 sends a paymentintent to the third party payment processor 106 (block 728). The paymentintent may cause the third party payment processor 106 to collectpayment information from the user (e.g., via the payment processorwidget, etc.) and/or place a hold on funds sufficient to pay thecalculated cost. The commerce platform 102 then makes a call to the IMSof the merchant 104 to place a reserve on the selected inventory (block730). The reserve temporarily prevents the entries in the inventorydatabase 132 representative of the inventory from being reserved orotherwise purchased. The commerce platform 102 then signals to thebrowser that the inventory is reserved (block 732).

The browser, using the instantiating script, presents the entryauthorization interface 600A (block 733). Upon entry of identifiers inthe identifier fields 602A and 602B, the browser, using theinstantiating script, presents a first authorization challenge via thefirst challenge authorization interface 600B (block 734). In someexamples, the authorization challenges are by entry of a secret receivedvia and tied to the corresponding identifier (e.g., a mobileapplication-based one-time passcode (e.g., a HMAC-based One-timePassword algorithm (HOTP) code, a Time-based One-time Password Algorithm(TOTP) code, etc.), a SMS or email-based one-time password (OTP) code, acode provided by a USB or embedded chip based key (sometimes referred toas a “smartcard” or a “security token”, etc.). Upon entry of the answerto the first authorization challenge via the first challengeauthorization interface 600B, via the instantiating script, the browserforwards the entry to the commerce platform 102 to determine if the userpasses the first authorization challenge.

The commerce platform 102 determines whether the entry provided by theuser passes the first authorization challenge and forwards thisdetermination to the browser (block 736). The user passes the firstauthorization challenge when, for example, the secret entered via thefirst challenge authorization interface 600B matches the expected secret(e.g., the secret via the medium associated with the first identifier).

The browser, using the instantiating script, determines whether the userpassed the first authorization challenge (e.g., it received the passsignal from the commerce platform 102) (block 738). When the user doesnot pass the first authorization challenge (“NO” at block 738), thebrowser again presents a first authorization challenge (block 734). Forexample, the user may fail the first authorization challenge by enteringa mismatched set of credentials, by entering the wrong OTP, and/orwaiting too long to enter the OTP. In some examples, the browser, usingthe instantiating script, may limit the number of times the firstauthorization challenge may be attempted before, for example,transmitting a message to the commerce platform 102 to end thetransaction (e.g., revoking the payment invent and unreserving theinventory, etc.). When the user does pass the first authorizationchallenge (“YES” at block 738), the browser, using the instantiatingscript, presents a second authorization challenge via the secondchallenge authorization interface 600C (block 740). For example, theuser may pass the first authorization challenge by entering the secretassociated with the identifier. The second authorization challengerequires entry of a different secret than the first authorizationchallenge that has a different source different than the secretinformation of the first authorization challenge. For example, the firstauthorization challenge may be entry of an OTP received from a SMSmessage and the second authorization challenge may be entry of adifferent OTP received from an email. In some examples, theauthorization challenges may be structured such that they may beperformed without the user having an account or prior relationship withthe commerce platform 102. In some examples, the first authorizationchallenge may require entry on a mobile phone number to which thecommerce platform 102 sends a first OTP and the second authorizationchallenge may require entry of an email address to which the commerceplatform 102 sends a second OTP. In such examples, these credentials(e.g., the mobile number and email address) may be associated with thepurchase intent such that future fulfillment requires entry of the samemobile number-email address pair (e.g., in response to subsequentauthorization challenges at the time of fulfillment, etc.). Although twoauthorization challenges are described herein, there may be fewer (e.g.,one) or more (e.g., three or more) authorization challenges. Upon entryof the answer to the second authorization challenge, via theinstantiating script, the browser forwards the entry to the commerceplatform 102 to determine if the user passes the second authorizationchallenge.

The commerce platform 102 determines whether the entry provided by theuser passes the second authorization challenge and forwards thisdetermination to the browser (block 742). The user passes the secondauthorization challenge when, for example, the secret entered via thesecond challenge authorization interface 600C matches the expectedsecret (e.g., the secret via the medium associated with the secondidentifier).

The browser, using the instantiating script, determines whether the userpassed the second authorization challenge (e.g., it received the passsignal from the commerce platform 102) (block 744). When the user doesnot pass the second authorization challenge (“NO” at block 744), thebrowser again presents a second authorization challenge (block 740). Insome examples, the browser, using the instantiating script, may limitthe number of times the second authorization challenge may be attemptedbefore, for example, transmitting a message to the commerce platform 102to end the transaction (e.g., revoking the payment invent andunreserving the inventory, etc.).

When the user passes the second authorization challenge (“YES” at block744), the commerce platform 102 makes a call to the IMS of the merchant104 to the selected inventory to be fulfilled (block 746). The commerceplatform 102 sends a payment order to the third party payment processor(block 748). The payment order causes the third party payment processorto complete the financial transaction based on the payment intent. Thecommerce platform changes the purchase intent to a purchase order andprepares for fulfillment (e.g., perform post fulfillment tasks, such asgathering shipping information, etc.) (block 750).

FIG. 8 illustrates an example method to perform authorization for thecommerce platform 102. Initially, the browser, using the instantiatorscript and the offer package 120, provides the entry authorizationinterfaces 600A to prompt entry of the identifiers into the identifierfields 602A and 602B (block 802). The offer package 120 may, forexample, specify the type of identifiers to be requested via the entryauthorization interfaces 600A. Upon receipt of the identifiers, theauthentication manager 125 and/or one of the authorization services 134operating on the servers 108 generates a first OTP for the firstidentifier (e.g., the identifier entered into the first identifier field602A) (block 804). The authentication manager 125 and/or one of theauthorization services 134 provides the first OTP via the mediumassociated with the first identifier (block 806). For example, the oneof the authorization services 134 may interface with an SMS system tosend the first OTP to a mobile device using the first identifier (inthis example, a mobile number). As another example, a different one ofthe authorization services 134 may interface with an email system tosend the first OTP to an email account using the first identifier (inthis example, an email address). As another example, a different one ofthe authorization services 134 may interface with an instant messagingsystem to send the first OTP to a messenger using the first identifier(in this example, an instant messenger handle).

The browser, using the instantiating script, provides for entry of thefirst OTP via the first challenge authorization interface 600B (block806). In some examples, the browser, using the instantiating script,provides the first challenge authorization interface 600B immediatelyafter receiving the identifiers even if the first OTP has not beengenerated yet. The authentication manager 125 waits for input into thefirst challenge authorization interface 600B to be communicated by thebrowser (block 808). Upon receipt, the authentication manager 125determines whether an entry into the secret entry field(s) 606A of thefirst challenge authorization interface 600B matches the first OTP(block 810). The authentication manager 125 also tracks the pass/failstatus of the user through the two authentication challenges so to onlyauthorize the user (e.g., and the associated transaction) if the userpasses both of the authentication challenges. If it does not match (“NO”at block 812), the authentication manager 125 reports that theauthentication has failed (e.g., sends a fail signal to the browser)(block 814). When it does match (“YES” at block 812), the authenticationmanager 125 reports that the authentication has passed (e.g., sends apass signal to the browser) (block 816).

The authentication manager 125 and/or one of the authorization services134 operating on the servers 108 generates a second OTP for the secondidentifier (e.g., the identifier entered into the second identifierfield 602B) (block 818). The authentication manager 125 and/or one ofthe authorization services 134 provides the second OTP via the mediumassociated with the second identifier (block 820). The browser, usingthe instantiating script, provides for entry of the second OTP via thesecond challenge authorization interface 600C (block 822). Theauthentication manager 125 waits for input into the second challengeauthorization interface 600C to be communicated by the browser (block824). Upon receipt, the authentication manager 125 determines whether anentry into the secret entry field(s) 606B of the second challengeauthorization interface 600C matches the second OTP (block 826). If itdoes not match (“NO” at block 826), the authentication manager 125reports that the authentication has failed (e.g., sends a fail signal tothe browser) (block 814). When it does match (“YES” at block 826), theauthentication manager 125 reports that the authentication has passed(e.g., sends a pass signal to the browser) (block 828).

Additionally, when the entry into the secret entry field(s) 606B of thesecond challenge authorization interface 600C matches the second OTP,the authentication manager 125 determines whether both authenticationchallenges pass (block 830). If either one of the authenticationchallenges fail (“NO” at block 830), the authentication manager 125cancels the authentication and does not allow the correspondingtransaction (block 830). When both authentication challenges pass (“YES”at block 830), the authentication manager 125 authorizes the user andallows the corresponding transaction (block 834). The authenticationmanager assigns the transaction to a record in the customer database 126(block 834).

In parallel or serial to block 804 to block 828, the authenticationmanager 128 queries the customer database 126 for a record thatcorresponds to both of the identifiers (block 836). When a record existsthat corresponds to both of the identifiers (“YES” at block 836), theauthentication manager retrieves or otherwise references that record toassign to the transaction (e.g., at block 834) (block 838). When arecord does not exist that corresponds to both of the identifiers (“NO”at block 836), the authentication manager 125 creates a record to assignto the transaction (e.g., at block 834) (block 840).

Although the embodiments of the present invention have been illustratedin the accompanying drawings and described in the foregoing detaileddescription, it is to be understood that the present disclosure is notto be limited to just the embodiments disclosed, but that the disclosuredescribed herein is capable of numerous rearrangements, modificationsand substitutions without departing from the scope of the claimshereafter. The terms “includes,” “including,” and “include” areinclusive and have the same scope as “comprises,” “comprising,” and“comprise” respectively. The claims, as follows, are intended to includeall modifications and alterations insofar as they come within the scopeof the claims or the equivalent thereof.

1. A network traffic surge resistant system comprising: a commerceplatform configured to manage a surge network traffic, wherein thecommerce platform comprises: a customer database that stores customerinformation to facilitate assigning an order from a checkout interfacein a browser to a particular account for security and fulfillment; atransaction API that facilitates communication between one or moreservers, a payment processor, a merchant network, and the customerdatabase of a customer; and a packager that receives input from amerchant to generate an offer instantiator and an offer package usingsoftware bricks, stored in the packager, that define one or more ofparameters, metadata, available inventory, and audiovisual assets of anoffer; wherein the offer package contains information necessary for theoffer instantiator, when accessed by a browser, to render a cartinterface and a checkout interface, including a description of theavailable inventory to facilitate a customer browsing the inventorythrough the cart interface, without making any backend calls to the oneor more webservers or the transaction API; and wherein after the offerinstantiator and the offer package are generated, the packager publishesthe offer instantiator onto the one or more servers and pushes the offerpackage onto the network storage, with a link to the offer instantiatorbeing transmitted to the customer.
 2. The network traffic surgeresistant system of claim 1 wherein the offer instantiator is located ona server and is accessible via a domain that is operated by the commerceplatform, or alternatively, the offer is located on another server andis accessible via a domain that is operated by another party such as bythe merchant network or a third party.
 3. The network traffic surgeresistant system of claim 1 wherein the merchant dynamically andasynchronously update the offer package with new or updated parameters,new or updated metadata, new or updated available inventory, or new orupdated audiovisual assets for an updated offer package by transmittinginput to the packager to push the updated offer package to replace theoffer package, while the customers access the offer instantiator withoutinterruption.
 4. The network traffic surge resistant system of claim 1wherein the merchant network comprises an inventory database and aninventory interface that uses the inventory database to provide theinventory data object, wherein the inventory interface changes a statusof an inventory such as reserving the inventory or marking the inventoryfor fulfillment, and wherein the inventory interface limits a frequencyat which the packager requests a refresh of the inventory data object.5. The network traffic surge resistant system of claim 4 wherein uponactivating the link to the offer instantiator, the browser performs astatic call to retrieve the offer package and an instantiating script torenter the cart interface, wherein the cart interface performspre-checkout cart management functions using resources of the browser,and wherein the pre-checkout cart management functions include browsinginventory as defined by the inventory data object, as processed by thesoftware bricks.
 6. The network traffic surge resistant system of claim1 wherein upon activating an action button, the browser renders, basedon the offer package, the checkout interface and makes a backend callthat includes inventory unit identifiers that identify current inventoryin a current cart of the cart interface and quantities of the currentinventory in the current cart of the cart interface, and wherein thebackend call causes the one or more servers to calculate an actual costof items in the current cart, including a unit cost of the items andassociated fees, and report that total to the checkout interface.
 7. Thenetwork traffic surge resistant system of claim 6 wherein the checkoutinterface displays the total and performs a redirect to the paymentprocessor that causes the payment processor to instantiate one or morepayment electronic widgets or credit card payment widget in the checkoutinterface.
 8. The network traffic surge resistant system of claim 1further comprising an authentication manager that manages authenticationof the customer and protects the customer database from negative effectsof surges in network traffic that result in frequent queries into thecustomer database.
 9. The network traffic surge resistant system ofclaim 8 wherein the authentication manager authorizes a transactionbased on a determination whether the customer enter secrets matchingidentifiers requested by one or more authorization challenge interfaces.10. A network traffic surge resistant system comprising: networkstorage; and one or more servers configured as a commerce platform, thecommerce platform configured to: generate a script, an offer package,and an offer instantiator; store the script and the offer package ontothe network storage, the offer instantiator providing the location ofthe script and the offer package in the network storage; wherein, inresponse to a browser operating on a computing device accessing theoffer instantiator, causing, by the offer instantiator, the browser toretrieve the script and the offer package from the network storage. 11.The network traffic surge resistant system of claim 10 wherein thecommerce platform comprises an authentication manager, and wherein, inresponse to a signal from the commerce platform, causing, by the scriptand based on the offer package, the browser to instantiate anauthorization interface to receive entry of first and second identifiersand first and second input codes; and wherein the authentication manageris configured to: generate a first secret code and send the first secretcode via a first communication medium associated with the firstidentifier; generate a second secret code and send the second secretcode via a second communication medium associated with the secondidentifier; and in response to determining the first input code matchingthe first secret code and the second input code matching the secondsecret code, authorize a transaction associated with the browser andassociate the transaction with a customer record associated with boththe first and second identifiers.
 12. The network traffic surgeresistant system of claim 11, wherein the authentication manager isconfigured to query a customer database for the customer record usingthe first and second identifiers to query the customer database.
 13. Thenetwork traffic surge resistant system of claim 12, wherein theauthentication manager is configured to: generate and send the firstsecret code at a first time; generate and send the second secret code atthe first time; and query the customer database at a second time afterthe first time, the second time being (a) after determining that thefirst input code matches the first secret code and the second input codematches the second secret code and (b) before the authentication managerauthorizes a transaction.
 14. The network traffic surge resistant systemof claim 12, wherein authentication manager is configured to generateand send the first secret code at a first time, generate and send thesecond secret code at the first time, query the customer database atsubstantially the same time.
 15. The network traffic surge resistantsystem of claim 12, when (a) the first input code matches the firstsecret code and the second input code matches the second secret code,and (b) the customer record associated with the first and the secondidentifiers does not exist in the customer database, the authenticationmanager is configured to create the customer record associated with thefirst and the second identifiers.
 16. The network traffic surgeresistant system of claim 11, wherein the first communication medium isa first type of communication medium and the second communication mediumis a second type of communication medium that is different than thefirst type.
 17. The network traffic surge resistant system of claim 16,wherein the first type of communication medium is a mobile network andthe first identifier is a mobile number, and the second type ofcommunication medium is email and the second identifier is an emailaddress.
 18. The network traffic surge resistant system of claim 11,wherein the authentication manager is configured to, in response todetermining that the first input code does not match the first secretcode or the second input code does not match the second secret code,cancel the transaction and perform inventory management to releaseinventory associated with the transaction.
 19. The network traffic surgeresistant system of claim 11, wherein the first and second secret codesare generated without first determining whether the customer recordassociated with the first and second identifiers exists within thecustomer database.
 20. The network traffic surge resistant system ofclaim 11, wherein to cause the browser to instantiate the authorizationinterface, the script generates instructions, using the resources of thecomputing device, for the browser to execute based on the offer package.